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Abstract 



This paper re-examines the presentation of datatypes in dependently typed languages, addressing 
in particular the issue of what it means for one datatype to be in various ways more informative 
than another. Informal human observations like 'lists are natural numbers with extra decoration' 
and 'vectors are lists indexed by length' are expressed in a first class language of ornaments — 
presentations of fancy new types based on plain old ones — encompassing both decoration and, in 
the sense of Tim Freeman and Frank Pfenning (1991), refinement. 

Each ornament adds information, so it comes with a forgetful function from fancy data back to 
plain, expressible as the fold of its ornamental algebra: lists built from numbers acquire the 'length' 
algebra. Conversely, each algebra for a datatype induces a way to index it — an algebraic ornament. 
The length algebra for lists induces the construction of the paradigmatic dependent vector types. 

Dependent types thus provide not only a new 'axis of diversity' — indexing — for data structures, 
but also new abstractions to manage and exploit that diversity. In the spirit of 'the new program- 
ming' (McBride & McKinna, 2004), the engineering of coincidence is replaced by the propagation 
of consequence. 



If it is not a peculiar question, where do datatypes come from? Most programming lan- 
guages allow us to declare datatypes — that is to say, datatypes come from thin air. 
Programs involving the data thus invented subsequently become admissible, and if we are 
fortunate, we may find that some of these programs are amongst those that we happen to 
want. What a remarkable coincidence! 

In dependently typed programming languages, the possible variations of datatypes are 
still more dense and subtle, and the coincidences all the more astonishing. For example, 
working in Agda (Norell, 2008), if I have list types, declared thus, 

data List (X : Set) : Set where 



: X -> List X -> List X 

I might seek to define zip, the function which rearranges a pair of lists into a list of pairs. 
Inevitably, I will face the question of what to do in the 'off-diagonal' cases, where one list 
is shorter than the other. 



1 Introduction 



[] 



ListX 
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zip : V {X Y} -^L\stX^ List Y -> List (X x Y) 

zipO D =0 

zip [] (y :: ys) = ? 

zip (x :: xs) [] = ? 

zip (x :: xs) (y :: ys) = (x,y) :: zip xsys 

One possibility is to return a dummy value, perhaps [], as in the Haskell standard Pre- 
lude (Peyton Jones, 2003). However, this practice can often mask the presence of a bug: 
indeed, I found such a bug in an early version of Agda. Such cautionary tales might prompt 
me to declare vectors instead. 

data Vec (X : Set) : Nat -> Set where 

: Vec X zero 

_::_ : X -> V {n} -> Vec X n -> VecX (sue n) 

As it happens, simple unification constraints on indices rule out the error cases and allow 
us stronger guarantees about the valid cases: 

zip : V {X Y «} -> VecX « -> Vec 7 « -> Vec (X x T) « 

z|pO D =0 

zip (x :: xs) (y :: ys) = (xy) :: zipxsys 

These vectors may look a little strange, but perhaps they are in some way related to lists. 
Do you think it might be so? Could we perhaps write functions to convert between the two 

vecList : V {X n} — > Vec Xn — > List X — forgets index 

listVec : V {Xn} — > (xs : ListX) — > VecX (f xs) — recomputes index with f 

for a suitable f : V {X} — ► ListX — > Nat? What might f be? I know a function in the library 
with the right type: perhaps length will do. 

But I am being deliberately obtuse. Let us rather be acute. These vectors were conceived 
as a fancy version of lists, so we should not be surprised that there is a forgetful function 
which discards the additional indexing. Further, the purpose of indexing vectors is to 
expose length in types, so it is not a surprise that this index can be computed by the length 
function. Indeed, it took an act self-censorship not to introduce vectors to you in prose, 
'Vectors are lists indexed by their length.', but rather just to declare them to you, as I might 
to a computer. 

In this paper, I show how one might express this prose introduction to a computer, 
constructing the vectors from the definition of length in such a way as to guarantee their 
relationship with lists. The key is to make the definitions of datatypes first-class citizens 
of the programming language by establishing a datatype of datatype descriptions — a 
universe, in the sense of Per Martin-L6f (1984). This gives us an effective means to frame 
the question of what it is for one datatype to be a 'fancy version' of another. 

I shall introduce the notion of an ornament on a datatype, combining refinement of 
indexing and annotation with additional data. Ornaments, too, are first-class citizens — we 
can and will compute them systematically. This technology allows us not only to express 
vectors as an ornament on lists, but lists themselves as an ornament on numbers. Moreover, 
the former can be seen as a consequence of the latter. 
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The work I present here is an initial experiment with ornaments, conducted in Agda, 
but with the intention of delivering new functionality for Epigram (McBride & McKinna, 
2004), where the native notion of datatype is now delivered via a universe (Chapman et ah, 
2010). It is ironic that an Agda formalisation of ornaments is no use for programming with 
Agda's native datatypes, good only for those datatypes within the formal universe. It is 
this distinction between the native data and their formal forgeries which must be abolished 
if this technology is to achieve its potential, and in the rudimentary Epigram prototype, it 
has been. Here, however, I am happy to exploit the more polished syntax of Agda to assist 
in the exposition of the basic idea. The literate Agda source for this paper is available at 
http : //personal . cis . strath . ac . uk/~conor/pub/0AA0/Lit0rn . lagda. 

Related Work 

There is a rich literature on refinement types, initially conceived by Tim Freeman and Frank 
Pfenning (1991) as a kind of 'logical superstructure' for ML datatypes, and extensively 
pursued by Frank Pfenning and his students. Refinement types are at the heart of Hongwei 
Xi's design for Dependent ML (Xi & Pfenning, 1999): programs are checked at advanced 
types guaranteeing safety properties, then erased to Standard ML for execution. Rowan 
Davies (2005) and Joshua Dunfield (2007) further study types and type checking in this 
setting where the computational substrate is without dependent types. 

More recently, William Lovas and Frank Pfenning (2010) have adapted the notion to 
the Logical Framework, allowing the construction of subset types with proof irrelevance. 
Matthieu Sozeau (2008) gives a treatment of programming with subset types for a proof- 
irrelevant incarnation of Coq which has not entirely materialised. 

I profit from the insights of the refinement type literature, but in a more general setting 
— full dependent types with proof-irrelevant propositions (Altenkirch et ai, 2007) — and 
with greater fluidity. Refinements are one kind of ornament, but here we shall see that 
decoration with additional non-logical data fits in the same scheme. It becomes interesting 
to condsider the erasure functions which ornaments induce as helpful first-class functions, 
programmed for free, not just as the erasure preceding execution. We shall surely want 
to work with both lists and vectors, for example, but without the need to spend effort 
establishing the connection between them. 

Literally and metaphorically closer to home, my Strathclyde colleagues Robert Atkey, 
Neil Ghani and Patricia Johann (2011) have recently made a study of type refinements 
induced by algebras over a datatype's structure — the algebraic ornaments of this paper's 
title — citing an early draft of this paper amongst their motivation. Their paper gives a 
crisp and enlightening categorical account of the broad semantic structure of algebraic or- 
naments via fibrations, abstracting away from the details of a particular universe encoding. 
I compliment and complement their work, giving a concrete implementation, and showing 
how algebras arise from ornaments in my more general decoration-and-refinement sense. 
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2 Describing Datatypes 

In order to manipulate inductive (tree-like) datatypes, we shall need to represent their 
descriptions as data, then interpret those descriptions as types. That is, we must construct 
what Per Martin-L6f calls a universe (Martin-L6f, 1984). The techniques involved here 
are certainly not new: Marcin Benke, Peter Dybjer and Patrik Jansson (2003) provide a 
helpful survey. Here, I follow the recipe from Peter Dybjer and Anton Setzer's coding of 
induction-recursion (Dybjer & Setzer, 1999), suitably adapted to the present purpose. 

2.1 Unindexed inductive datatypes 

Let us start with plain unindexed first-order data structures, just to get the idea. You can 
interpret a plain Description as a format, or a program for reading a record corresponding 
to one node of a tree-like data structure. 

data Desc : Setl where 

end : Desc — end of node 

cr : (S : Set) — > (5 — > Desc) — > Desc — dependent pair 

nodex_ : Desc — > Desc — subnode, then more 

The description runs left-to-right, with end signalling the end of the node, cr S D indicating 
an element s : S followed by the rest described by D s, and nodex D marking a place for 
a subnode followed by more data described by D. 

An imaginary Robert Harper reminds me to remark that the use of functions to account 
for type dependency in the cr constructor does not constitute 'higher-order abstract syntax' 
in the sense of the Logical Framework (Harper et al., 1993). In terms of polarity (Licata 
et al, 2008), the 'positive' LF function space is restricted to correspond exactly to variable 
binding, but here I use the full 'negative' function space which allows actual computation, 
admitting the so-called 'exotic terms' which destroy the crucial adequacy property of 
HOAS representations. This choice is quite deliberate on my part: I make essential use 
of that extra computational power, as I shall shortly demonstrate. 
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Let us have an example description: if we have a two element enumeration to act as a set 
of tags, we may describe the natural numbers. I name the enumeration [ze, su], a suggestive 
identifier, and I exploit Agda's mixfix notation to give a convenient case analysis operator, 
especially suited to partial application. 

data [ze,su] : Set where zesu : [ze,su] 

zei->_sjH^_ : V {a} — > {P : [ze, su] — > Set a} — > P ze — > P su — > (c : [ze,su]) — > P c 
(zei— >z sui— >s)ze = z 
(zei— >z suh^5)su = s 

Ulf Norell's (2007) rationalisation of Randy Pollack's (1992) argument synthesis incorpo- 
rates Dale Miller's (1992) pattern unification, which will infer a suitably dependent P just 
when case analysis is not fully applied to a scmtinee. 

Now we can use the fully computational dependency built into the o" construct to treat 
'constructor choice' as just another component of a variant record. 

NatP : Desc 

NatP = cr [ze,su] (zei— > end suh> nodex end) 

What does this say? A natural number node begins with a choice of tag; if the tag is ze, we 
have reached the end; if the tag is su, we require one 'predecessor' subnode, then end. 

We shall need to interpret descriptions as actual types in a way which corresponds to 
the explanation above. To do so, we may follow the standard construction of an induc- 
tive datatype as the initial algebra of an endofunctor on Set which drives the algebra of 
programming view of data and functions (Bird & de Moor, 1997). If we have a set X 
representing subnodes, we can give the set representing whole nodes as follows. 

[_] : Desc -> Set -> Set 

[[end }X = 1 

laSD }X = ISA s -> {DsjX 

I nodex DjX = Xx {DjX 

Here, 1 is the unit type, with sole inhabitant () and L S T is the type of dependent pairs s, t 
(unparenthesized) such that s : S and t : T s. Agda extends the scope of a A rightwards 
as far as possible, reducing the need for parentheses. Note that S x T is defined to be the 
non-dependent special case L S A _ — > T. 

Correspondingly, if Nat were the type of natural numbers, we should have 

[ NatP ] Nat = I [ze,su] (zei-> 1 sui->Natxl) 

But how can we define such a Nat, given NatP? This [[_] interprets a description as a strictly 
positive operator on sets, so we are indeed entitled to an inductive datatype Data D, taking 
a fixpoint, instantiating X with Data D itself. 



data Data (D : Desc) : Set where 
(_) : [D] (DataD) -> DataD 



ZU064-05-FPR LitOrn 23 January 201 1 1:57 



6 Conor McBride 

We may thus define the set of natural numbers, and its constructors. 

Nat : Set zero : Nat sue : Nat^ Nat 

Nat = Data NatP zero = (ze, ()) sucn = (su,n, ()) 

Sadly, Agda will not let us use these definitions in pattern matching, so we shall be forced 
to face artefacts of encoding as we work. Encoded datatypes make William Aitken and John 
Reppy's (1992) proposed notion of definition fit for left and right still more overdue. 

We could go on to develop the initial algebra semantics for this class of functors, but let 
us first generalise to the indexed case. 



2.2 Indexed inductive types 



We can give a type which describes inductively defined families of datatypes in / — > Set (Dy- 
bjer, 1994). Vectors, parametrized by their element type but indexed by their length, are a 
typical example. Let us revisit them and examine theor salient features. 



parameter index set 



data Vec 



(X : Set) 



Nat 



Set where 

: VecX 
: X -> V { n } -> Vec X [n] -> Vec X 

T 



zero 
(sue n) 



constructor choice 



subnode index 



node index 



All that changes is that we must ask for a specific index anytime we need a subnode, and 
we must say which index we deliver when we reach the end of a node. Let us adapt our 
coding system to account for these extra details. 



data Desc (/ : Set) : Setl where 



say 
fl- 
ask.* _ 



(5 : Set) (D : S 
I -> Desc / -> 



Desc /) 



Desc / 
Desc / 
Desc / 



Accordingly, the description of vectors is as follows: 



VecD : Set -> Desc Nat 
VecD X = a [ze, su] ( 
zei— > 

su i— > cX A x — > ff Nat A n 



say zero 
ask n * say (sue «)) 



We interpret descriptions again as strictly positive endofunctors, but this time on / — > Set. 
We are given the indexed family of recursive subnodes X : I — > Set, and we must deliver 
an indexed family of nodes inl — > Set. In effect we are told the index which the node must 
say. Hence, we should interpret the say construct with an equality constraint: i = i, here, 
is the usual intensional equality type, allowing constructor ref I whenever i' is definitionally 
equal to i. When the description asks, we know at which index to invoke X. The treatment 
of cr is just as before. 
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I_] : V {/} -► Desc /-►(/-► Set) -> (/ -> Set) 

[ say i' jXi=if = i 

laSD jXi = LSXs^lDsjXi 

I ask i' * D ] X i = X if x [ D ] X i 

Of course, we acquire inductive datatypes by taking the least fixpoint. 

data Data {/ : Set} (D : Desc/) (i : I) : Set where 
(_) : [D] (Data D) i -> Data D i 

Unindexed datatypes like Nat still fit in this picture, just indexing with 1 and inserting 
trivial indices where required: 

NatD : Desc 1 

NatD = o" [ze,su] (zen say () sun ask () * say ()) 

The corresponding type and value constructors acquire trivial indices and proofs. 

Nat : Set zero : Nat sue : Nat -> Nat 

Nat = Data NatD () zero = (ze, refl) suc« = (su,n, refl) 

However, we are now in a position to implement the type and value constructors for 
nontrivially indexed structures, like the vectors: 

Vec : Set -> Nat -> Set 
VecXn = Data (VecDX) n 

[} : V{X} -> Vec X zero 
[] = (ze,refl) 

_::_ : V {X} -> X -> V {«} -> VecX n -> VecX (sue n) 
-::-x{n}xs = ( su, x,n,xs, refl ) 

There are many ways to go about the encoding of inductive families. This choice is 
rather limited in that it does not allow infinitely branching recursion, and rather rigid in 
that it prevents us from using the node index a priori to compute the node structure. There 
is no barrier in principle to adapting the techniques of this paper for more sophisticated 
encodings (Chapman et ai, 2010), but there is, I hope, a pedagogical benefit in choosing 
an encoding which corresponds straightforwardly and faithfully to the more familiar mode 
of defining inductive families in type theory or the 'Generalized Algebraic Data Types' 
now popular in Haskell (Cheney & Hinze, 2003; Xi et ai, 2003; Sheard, 2004; Peyton 
Jones et ai, 2006). 

3 Map and Fold with Indexed Algebras 

It is not enough to construct data — we must compute with them. In this section, I describe 
standard 'algebra of programming' apparatus, but for indexed data structures, and then 
show how to implement it for the indexed datatypes described by Desc/. 

Informally, when presenting an inductive datatype as the initial algebra, in : F (u.F) — > \iF, 
for a suitable functor F : Set — > Set, we provide the action of F on functions, lifting 
operations on elements uniformly to operations on structures 
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map F : V{XF}->(X-»F) — ►FX— >FF 

and are rewarded with an iterator, everywhere replacing in by (p. 

fold F : V{X} -> (FX^X) ^[if 
fold/? 0 (in t/i) = 0 (mapf (foldf 0) c/i) 

We can think of F as a signature, describing how to build expressions from subexpressions, 
and p. F as the syntactic datatype of expressions so generated. An algebra 0 : F X — ► X 
explains how to implement each of the signature's expression-forms for values drawn from 
X — we say that 0 is an F-algebra with carrier X. If we know how to implement the 
signature, then we can evaluate expressions: that is exactly what fold/? does, first using 
map/- to evaluate the subexpressions, then applying 0 to deliver the value of the whole. 

Let us play the same game with our operators on / — > Set. We must first characterise the 
morphisms or 'arrows' of I — > Set — functions which respect indexing. 

: V {/} -» (/ -» Set) -►(/-> Set) -> Set 
X-»Y = V{i}->Xi->Yi 

The usual polymorphic identity and composition specialise readily to these arrows, 
verifying the standard categorical laws. We can revert to using unindexed types by instan- 
tiating X and Y with constant functions, conveniently given by the usual K combinator, 
where k j 5 = 5. 

We are now in a position to equip our descriptions with their functorial action on arrows. 

map : V{IXY} -> (D : Desc/) -> (X -h- F) -» [D] X -H- [£> ] F 

map (say ;) / ^ = g 

map(o"5'Z)) f (s,ds) = s, map (Ds)fds 

map (ask / * D)f (d,ds) =fd,mapDfds 

We might correspondingly hope to acquire an iterator, taking any index-respecting alge- 
bra and performing the index-respecting evaluation of indexed expressions. 

fold : V{IX} {D : Desc/} ([D] X -*X) -> Data D ^X 
fold {D = D} <p (ds) = <p (map D (fold <j>) ds) 

Frustratingly, Agda rejects this definition as less than obviously terminating. Agda's termi- 
nation oracle cannot see that map will apply fold (j) recursively only to subterms of ds. One 
might seek to improve the oracle's perspicacity, or better, to express the requirement which 
map satisfies by type — Abel's sized type discipline (Abel, 2006) is certainly adequate to 
this task. Locally, however, we can expose a satisfactory subterm structure just by long- 
windedly specialising map to its instance for fold. 

mutual 

fold : V{IX} {D : Desc/} ->p]X-^X)-> Data D ^X 
fold {D = D}(j> (ds) = <j) (mapFold£>D0 ds) 

mapFold : V {/ X} (D E : Desc/) -> ([DjX -h-X) -> 

[£|(DataZ))^[£]X 
mapFold D (say ;') (j) q =q 
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mapFold D (c S E) (j) (s,xs) = s, mapFold D (E s) 0 xs 

mapFold D (ask i * E) 0 (x,xs) = fold 0 x, mapFold D E (j) xs 

We see here the first instance of a recurring pattern in this paper. We process nodes of 
recursive structures a little at a time, retaining a fixed description D for the main structure, 
whilst a helper function walks through E, the description of the current node's tail, invoked 
with E — D. It reminds me of coding division by primitive recursion, when I was a boy. 
Lots of popular operations can be expressed as folds. For example, addition. . . 

addA : Nat — > [ NatD ] (k Nat) -^*Nat 
addA y (ze, _) = y 
addAy (su,z,_) = sucz 
: Nat^ Nat^ Nat 
x + y = fold (addAy) x 

. . . and vector concatenation — note the careful abstraction of m in the carrier of the 
algebra: 

concatA : V {X n } -> Vec Xn-» 

[ VecD X ] (A m -> Vec X (m + «)) -h (A m -> Vec X (m + n)) 
concatA ys (ze, refl) = ys 

concatA ys (su,x, -,zs, refl) = x::zs 

_++_ : V {m n X} -> Vec X m -> Vec Zn — > Vec X (m + n) 
xs++ys = fold (concatA ys) xs 

I hesitate to claim that fold delivers the most perspicuous definitions of these operations, 
especially given the visual overhead of the datatype encoding, but the point is that we 
can exploit the fact that these operations are folds in reasoning about them, and in per- 
forming further constructions. Epigram, of course, was originally conceived as a language 
combining a readable pattern matching syntax with definition by structural recursion op- 
erators (McBride & McKinna, 2004), so we may reasonably hope to have the best of both 
worlds. Whether or not you view it as desirable, it is not necessary to adopt a pointfree 
style of programming to work with recursion schemes. 

4 Ornaments and their Algebras 

In this section, I shall introduce the idea of ornamenting an indexed data structure, combin- 
ing the business of decorating a datatype with extra stored information and that of refining 
a datatype with a more subtle index structure. By constructing a fancy datatype in this way, 
we establish, for free, an algorithmic relationship with its plain counterpart. 

Suppose we have some description D : Desc / of an /-indexed family of datatypes (e.g., 
lists indexed by 1). Now suppose we come up with a more informative index set / (e.g., 
Nat), together with some function e : J — > / which erases this richer information (e.g., 
!, the terminal arrow which always returns ()). Let us consider how we might develop a 
description D' : Desc / (e.g., for vectors) with the same recursive structure as D, but richer 
indexing in an e-respecting way. We should be able to always erase bits of a Data D' j to 
get an unadorned Data D (e j) (e.g., converting vectors to plain old lists). 
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How are we to build such a D' from Dl Certainly, wherever D mentions indices i : I, D' 
will need an index j such that ej = i. It will help to define the inverse image of e, as follows: 



data {/ J : Set} (e : J -> /) : / -> Set where 

ok :(/:/) -> « - 1 (ej) 

That is to say, okj : e _1 / if and only if e j and / are definitionally equal: only the js in 
;'s inverse image are ok. Notice that when we work with ! : / -> 1, ! ~ x () is a copy of /, 
because ! j is always () — if there is no structure to respect, it is easily respected. 

Now, let us think of a language Orn, for ornamenting a given description. We should 
be able to mimic the existing structure of descriptions making sure that every /-index is 
assigned a corresponding /-index. The first three constructors, below, overload the de- 
scription constructors and deliver just that capability, but the fourth, A for 'difference', does 
something more curious — it permits us to insert new non-recursive fields into the datatype 
upon which subsequent ornamentation may depend. This will prove important, because we 
may need more information in order to decide which /-indices to choose than was present 
in the original /-indexed structure, and we may want more information, anyway. 

data Orn {/} (/ : Set) (e :/—>•/) : Desc / -> Setl where 



say 


:{i 




e-U^ 




Orn/« 


' ( sa y 0 


a 


: (5 


Set) - 


,\/{D}^((s: 


S) -> Orn J e (D s)) - 


-> Orn/« 


> (aSD) 


ask_*_ 


:{i 


/}-> 


e- 1 i^V{D} 


-> Orn/eD^ 


Orn/< 


' (ask i * D) 


A 


: (5 


Set) - 


+ V{D}^(S- 


> Orn /<?£>) -> 


Orn/« 


•D 



Before we go the length of vectors, let us have a simple but crucial example, ornamenting 
natural numbers to get the type of lists. This ornament is a simple decoration without 
refinement: a list is a natural number with decorated successors ! 

ListO : Set -> Orn 1 ! NatD 
ListOX = cr [ze,su] ( 

zei-^ say (ok ()) 

suh^AIA _— ► ask (ok ()) * say (ok ())) 

The difference is given by the A, attaching an element of X in the su case. 

Now, an ornament is no use unless we can extract the new description to which it leads. 
To do this, we need only turn A to cr and drop the fancy indices into place. 

L„J : V {IJf}{D : Desc/} -> Orn //£>-> Desc/ 

[say (okj')J = sayy 

[dSO\ = oSXs^ [Os\ 

[ask (ok;) * 0\ = ask;* [O \ 

[ASO\ = aSXs^ [Os\ 

Checking the example, we define 

ListD : Set -> Desc 1 
ListDX = [ ListO XJ 

and may then take 
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List : Set — > Set 

ListX = Data (ListDX) () 

[] : V{X}^ L\stX 
[} = (ze,refl) 

: V {X} -> X -> List X -> List X 
.ac::xs = ( su,x,xs, refl ) 

acquiring lists with a 'nil' and 'cons'. 



Ornamental Algebras 

What use is it to construct lists from numbers in this way? By presenting lists as an 
ornament on numbers, we have ensured that lists carry at least as much information. Cor- 
respondingly, there must be an operation which erases this extra information and extracts 
from each list its inner number. In effect, we have made it intrinsic that lists have length. 
More generally, for every ornament O : Orn J e D, we get a forgetful map 

forget : V {I J e} {D : Desc/} (O : OmJeD) -> 
{; : /}^Data [_0\j—* DataD (ej) 

which rubs out the A information and restores the less informative index. As you might 
expect, we shall have 

length : V {X} -> List X -> Nat 
length {X} = forget (ListOX) 

With judicious reindexing via composition, we can see forget as an index-respecting 
function between /-indexed sets, and define it as a fold, given a suitable algebra. 

forget : V {I J e} {D : Desc/} (O : OmJeD) -> 

(Data [0\) -r> DataD ■ e 
forget O = fold (ornAlg O) 

where (9's ornamental algebra is given as follows 

ornAlg : V {I J e} {D : Desc/} (O : OmJeD) -> 

[ [0\ ] (Data D • e) -7* Data D ■ e 
ornAlg O ds — ( erase O ds) 

erase : V {I J e} {D : Desc/} {X : /-> Set} -> (O : Orn/eD) -> 

[Loj](x- e )^[D]z- e 

erase (say (ok/)) refl = refl 

erase (cr S O) (s,rs) = s, erase (O s) rs 

erase (ask (ok j) * O) (r,rs) = r, erase (9 rs 

erase (A S O) (s,rs) = erase (O s) rs — s is erased 

The hard work is done by the natural transformation erase, good for plain /-indexed 
stuff in general (so Data D in particular), erasing, as you can see in the last line, just those 
components corresponding to a A. We are also satisfying the index constraints — where 
we have an (X ■ e) j on the left, we deliver an X (e j) on the right, and in the say case, the 
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refl pattern unfies the js on the left, ensuring that proof obligation on the right is simply 
e j = e j. By defining ornaments relative to descriptions, we ensure a perfect fit. 

5 Algebraic Ornaments 

A [ D ] -algebra, (j), describes a structural method to interpret the data described by D, giving 
rise to a fold <j> operation, applying the method recursively. Unsurprisingly, the resulting 
tree of calls to 0 has the same structure as the original data — that is the point, after all. 
But what if that were, before all, the point? Suppose we wanted to fix the result of fold (j) 
in advance, representing only those data which would deliver the answer we wanted. We 
should need the data to fit with a tree of (j) calls which delivers that answer. Can we restrict 
our data to exactly that? Of course we can, if we index by the answer. 

For every description D : Desc /, every algebra <p : [ D ] / J yields an algebraic 
ornament, giving us a type indexed over pairs in I / / whose first component must coincide 
with the original /-index — so the erasure map is just fst — but whose second component 
is computed by (j). My colleagues give a semantic account of algebraic ornaments in terms 
of the families fibration (Atkey et ai, 201 1). In order to give a concrete implementation, I 
compute the algebraic ornament by recursion on the description D, inserting a /-value to 
index each recursive object asked for and steadily building a record of arguments for (j) so 
that we can compute and report a /-index for the whole node. Here we see another of this 
paper's routine techniques, the use of the currying operator, *<j> s t = <j> (s,t), to feed an 
algebra one mouthful at a time. 

algOrn : V{//} (D : Desc/) -> ([£>] / -=->/) -> Orn (I//) fst/3 
algOrn (say/) <p = say (ok (i, 0 refl)) 

algOrn (oSD) <p = cr S A s -> algOrn (D s) (a0 s) 

algOrn {/ = /} (ask i * D) (j) = A (/ i) Xj -> ask (ok (;J)) * algOrn D 

Working from left to right along the description, we satisfy <p 's hunger stepwise, until we 
are ready to drop the refl in at the right end. 

Our first example algebra gives us an example algebraic ornament: we can use the 
addA m to characterize those numbers of form m + d, acquiring a definition of iess-or- 
equal', which ornaments the type of the difference d, as follows: 

Le : Nat^ Nat -> Set 

Lemn = Data [ (algOrn NatD (addA m)) J ((),«) 

leBase : V {m} — > Leram 
leBase = ( ze, refl ) 

leStep : V{m«}->LemB^Lera (sue n) 
leStepjr = ( su, refl ) 

As a consequence of this construction, we acquire the 'safe subtraction' function. 

safeSub : (n m : Nat) — > Le m n — > Nat 
safeSub/iw = forget (algOrn NatD (addA;7i)) 

The safety proof does, in fact, encode the difference, so we need merely decode it. 
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6 Buy Lists, Get Vectors Free 

In section 4, we saw how to make type of lists from the type of natural numbers by an 
ornament, acquiring an ornamental algebra to measure list length in the process. In section 
5, we learned to extract an algebraic ornament from an algebra, adding an index to a set. 
Let us put the two together, taking the algebraic ornament of the ornamental algebra to 
make new ornaments from old. 

aOoA : V{//} {e : J -> 1} {D : Desc/} -> 

(O : Orn/e£>) ^Orn (I / (Data D ■ e)) fst [O \ 
aOoAO = algOrn [0\ (ornAlg O) 

Applying this recipe to the list ornament, we acquire the 'lists of a given length', also 
known as vectors. 

VecO : (X : Set) -> Orn (1 x Nat) fst (ListDX) 
VecOX = aOoA (ListOX) 

VecD : (X : Set) -> Desc (1 x Nat) 
VecDX = [VecOXj 

Vec : Set -> Nat -> Set 
MecXn = Data (VecD X) ((},«) 

We can define the vector constructors in terms of our primitive components. 

[] :V{X}^ Vec X zero 

0 = (ze.refl) 

_::_ : V {X n} -> X -> VecX n -> Vec X (sue «) 
= ( su,x, _,xs, refl ) 

Like any other, our new ornament has an ornamental algebra inducing a forgetful map: 

toList : \j {Xn}-> VecXn-> UstX 
toList{X} = forget (VecO X) 

We explained how to define vectors when we explained how to see lists as a decoration 
of their lengths! This additional structure becomes manifest once we bring decoration and 
refinement together under one roof. 

The Same Trick Twice 

We had an ornament, which give us an algebra, which gave us an ornament, which gave us 
an algebra. Surely that gives us an ornament which gives us an algebra! The first time, we 
got lists indexed by length; now we get vectors indexed by their lists, otherwise known as 
the inductive definition of list length. 

LengthO : (X : Set) -> Orn ((1 x Nat) x ListX) fst (VecDX) 
LengthO X = aOoA (VecO X) - = aOoA (aOoA (ListO X)) 

Length : {X : Set} — > ListX^ Nat — > Set 
Length {X} xs n = Data [LengthOXj (((),n),xs) 
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nilL : V {X} -> Length {X} [] zero 
nilL = ( ze, refl ) 

consL : V {X n} {x : X} {xs : List X} — > Length xs n — > Length (x :: xs) (sue n) 
consL / = ( su, _,_,_,/, refl ) 

The forgetful function takes us from the proof of a list's length to its representation as a 
vector. 

length Vec : V {X n} {xs : ListX} — > Length xsn — > MecXn 
length Vec{X} = forget (LengthO X) 

We have seen how to build the ornamental hierarchy, and to descend it with forgetful 
folds, throwing away index information. To climb the hierarchy, we need fold's dependent 
cousin, proof by induction. 



7 Induction 

We may prove a generic induction principle for all our datatypes at once. The construction 
amounts to an effective treatment of the fibrational analysis due to Bart Jacobs and Claudio 
Hermida (1998), recently generalised by my colleagues, Neil Ghani, Patricia Johann and 
Clement Fumex (2010). Let me make the statement. 

induction : {/ : Set} (D : Desc/) 

(P : {i : 1} -> Data D i -> Set) -> 

({/ :I}(ds: {Dj (DataD) i) -»• All DPds P {ds )) -> 
{i : 1} (x : Data D i) -> P x 

Unpacking this statement, what do we have? For the /-indexed datatype with description 
D, let P be a 'predicate' — I have slipped into the language of propositions and proof, but 
the same construction works for programming, too. To show that P holds for all x, we must 
show that P holds for each parent ( d ), given that it holds for all the Z)-children in d. We 
can compute what it means for P to hold for all those children, building a tuple of Ps. 

All : {/ : Set} (E : Desc/) {D : /-> Set} 

(P : {; : /} -> D i -> Set) 

{i : /}-> {EjDi^Set 
All (say/) =1 
All (aSE) P(s,e) = All (E s) P e 
All (ask i*E)P (d,e) = Pd x All^Pe 

My colleagues rightly point out that All is, up to bureaucratic isomorphism, the functor 
on indexed sets given by the initial algebraic ornament, describable as [_ algorn D (_) J . 
Ornamenting a datatype by its initial algebra expresses exactly the singleton property of 
being constructed uniquely from constructors, which holds for all elements, of course. The 
essence of the fibrational analysis is that induction on a datatype amounts to iteration on 
its family of singletons. I chose not to use that construction in this paper only because 
my simple but rigid Desc formulation renders it awkwardly, where the All above neatly 
computes the tuple structure from the record which indexes it. 
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The implementation of induction is thus suspiciously like that of fold. As a first attempt, 
we may try to define induction via a map-like operator. 

induction D P p (ds) = p ds (everywhere D P (induction D P p) ds) 

everywhere : {/ : Set} (E : Desc/) {D : / — > Set} 

(P : {i : 1} —> D Set) -> 

({» :/)»•)-» fx)- 

{/ :/}(<*: [[ £]£>/)-> All 
everywhere (say ;') P P - = () 
everywhere (cr 5 E) P p (s,e) = everywhere (£ s) Pp e 
everywhere (ask i * E) P p (d, e) = p d, everywhere E P p e 

As with fold, Agda cannot see why the unapplied recursive induction is justified: it does 
not trust that everywhere will apply the given method only to subobjects of d. Again, we 
can make the structural recursion clear by specializing everywhere to induction. 

mutual 

induction : {I : Set} (D : Desc/) (P : {i : /} -> Data D i — ► Set) -> 

({/ : I}(ds : [£>] (DataD)/)^AIIDP*^P(&))^ 

{i : 1} (x : Data/);) -^Pi 
induction D f/7 ( ds ) = /? ds (everylnd D D Pp ds) 
every I nd : 

{/ : Set} (ED : Desc/) 

(P : {i : /} -> Data D i -> Set) -> 

({/ : /} (rf : [D] (Data/)) f) -»■ All D P d — P { d )) -> 

{/ : /} : [£] (DataD) /) — fkWEPd 
everylnd (say i) DPp_ = () 
everylnd (cr S E) DPp(s,e) — everylnd (E s) D Pp e 
everylnd (ask i*E) D Pp (d,e) — induction D Pp d, everylnd E D Pp e 

We can use induction to prove properties of specific functions at a specific type. Here, 
for example, is what Bundy calls 'the E. Coli of inductive proof, associativity of addition: 

assoc : (xyz: Nat) -> ((jc + y) + z) = (x + (y + z)) 

assocxyz = induction NatD (A x :— > ((x + y) + z) = (x+ (y + z))) 

(v(ze^ (A — > refl) 

su i-^ v (A jc _ — > v A // _ — ■ sue ii //) 

))* 

Agda does not support a pattern matching presentation of programming or tactical proof 
with hand-crafted induction schemes, so I am obliged to write an inscrutable proof ex- 
pression, making use of the uncurrying operator (s,t) = f s t to split tuples. Moreover, 
while programmers rejoice when intermediate type information is suppressable, those very 
types are the intermediate hypotheses and subgoals which show the pattern of reasoning 
in proofs. The Curry-Howard correspondence does not extend to a good discipline of 
documentation! What you can perhaps make out from my proof is that assoc is not itself 



ZU064-05-FPR LitOrn 23 January 201 1 1:57 



1 6 Conor McBride 

a recursive definition: rather, the inductive step unpacks the inductive hypothesis, H, and 
delivers sue ii H, the proof that applying sue to both sides preserves the equation. 

Remembering, wholesale 

We can also use induction in generic programming. With apologies to Philip K. Dick, I 
shall show how to implement the inverse of forget, for every algebraic ornament. 

remember : V{//} {D : Desc/} (0 : [ D ] / /) -> let = LalgOrnD 0J in 
{; : /} -> (d : Data D i) -> Data D^ (i,fold 0 d) 

The type of remember says that we can turn a plain old d into its fancier /-indexed 
counterpart, delivering the very index computed by fold 0 d. For example, a list becomes 
a vector of its own length. 

The implementation of remember is framed by an induction, but the main work consists 
of melding the non-recursive data from the plain record with the fancy recursive data from 
the inductive hypotheses, inserting indices computed by fold 0 where required. 

remember {/}{/} {D} 0 

rid lie Lion D (X { i} d— > Data D^ (z, fold 0 d)) (X ds hs — > ( meld D 0 ds hs )) where 
D* = LalgOrnD^J 

meld : (E : Desc/) (y : {EjJ-^J) {i :/}(«:[£] (DataD) i) -> 
AII£(A {/}rf-> Data D^ 1 (;,fold 0 d)) e 
[ LalgOrnE'v'J 1 (Data D^) (;, ^ (mapFold DE (j) e)) 

meld (say i) y refl = refl 

meld(o"5£') \jf (s,e) hs = s.meld (Es) ( A Y s) e hs 

meld (ask i*E) \j/ (d,e) (h,hs) = j,h, meld E (a y/j) e lis where/' = folded 

Again, meld requires a recursion over the datatype structure, with E carrying the remain- 
der of the description (initially D) and y/ its remaining algebra (initially <p). As in algOrn 
itself, y/ is repeatedly curried and fed one piece at a time. 

Let us check our example. 

toVec : {X : Set} (xs : ListZ) -> Vec X (length xs) 
toVec{X} = remember (ornAlg (ListOX)) 

To show that remember <p and forget (algOrn (j>) are mutually inverse again requires 
induction. This is left as an exercise for the reader. 

8 The Recomputation Lemma 

Suppose we have a vector xs whose length index is n: what is length (toListxs)? We 
should be astonished if it were anything other than «, but how can we be sure? In this 
section, I shall prove that an index given by an algebraic ornament can be recomputed by 
the corresponding fold. 

Let us state this property formally. Given a description D and a \ D ] -algebra <j> over 
some /, we may construct the algebraic ornament Cft, and thence the fancy type Cft . D^ is 
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indexed by pairs, with the second component being a /. We may state that every fancy x's 
/-index can be recovered from its plain counterpart by fold 0. 

Recomputation : V {//} (D : Desc/) (<f> : [£>] J -=->/) -> 
letO 1 '' = algOrnD^;^ = [0* J in 

{//':!//} (* : Data D'' ij) -> fold 0 (forget 0^ jc) = snd y' 

The proof goes by induction on the fancy type, with an inner lemma fusing fold (j) with 
forget 0*. 

Recomputation {/} {J} D 0 = 

induction (A {ij}x^ fold (j) (forget 0* x) = snd ij) (fuse D <p) where 
Oft' = algOrn£>0;D 1 ?' = [O^J 

Of course, the forget is really a fold (ornAlg O 1 ^), so the heart of the proof shows how 
the two mapFolds combine to feed the algebra what we expect. The type of fuse follows 
our trusty pattern, abstracting the unprocessed description E and its hungry algebra yf. 

fuse : (E : Desc/) (yf : [ E ] / -h- /) -> let E^ = [algOn^ yj in 
{y :!//}(*: [E*](Data[*)y)-> 
All EV (A {y } x -> fold 0 (forget x) = snd y) e -> 
^(mapFoldZJE^ (erase (algOrn E yf) (mapFold Eft (ornAlgO^) e))) 
= snd ij 

fuse (say ;) yf refl /w = refl 

fuse (cSE) yf (s,e) hs = fuse (E s) ( A yf s) e hs 

fuse (ask i * E) yf (j,x, e) (h, hs) rewrite h — fuse E (a yf j) e hs 

In the ask i * E case, j is the index of x, and the goal asks us to show that 

yi (fold 0 (forget & x), ...) = snd y 

Agda allows us to rewrite by inductive hypothesis, 

/i : fold 0 (forget 0* x) =j 

so that we can feed j to i// and continue. When we reach the end of the record, we learn the 
value of its index ij — exactly the value we need. 

The recomputation lemma is, in some sense, a statement of the obvious. It tells us that 
if we can perform a construction at a higher level of precision, we automatically know 
something about its less precise counterpart. 

A Weapon of Math Construction 

Standing the recomputation lemma on its head, we acquire a construction method. Suppose 
we want to write some function 

f : A -* Data D i 

whose specification is of form fold 0 ■ f = g. That is, the output must have a particular 
interpretation, according to some algebra 0. Algebraically ornamenting D by 0 allows us 
to bake the specification into the type of the program. We can try to implement a fancier 
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function: 

f* : {a : A) -> Data [ LalgOrnD^J ] (i,ga) 
If we succeed, we may define 

f = forget (algOrn£>0) ■ f* 

and deduce that the specification is satisfied, gratis. Recomputation gives us that 

fold 0 (f a) = fold <j> (forget (algOrn D 0) (f* a)) = g a 

The outside world need not know that we used a rather fancy type to construct f correctly. 
The ornamentation technology allows us to localize the use of the high precision type. Let 
us put this method to work. 

9 Compiling Hutton's Razor Correctly 

James McKinna suggested that I investigate the following example, inspired by Graham 
Hutton's modus operandi. Consider a minimal language of expressions — natural numbers 
with addition, sometimes referred to as "Hutton's Razor". By way of a reference semantics, 
we may readily define an interpreter for this language, summing all the numerical leaves 
in a tree of additions. However, we might prefer to compile such expressions, perhaps to a 
simple stack machine. A correct compiler will guarantee to produce code which respects 
the reference semantics. We shall extract this result/or/ree from the recomputation lemma. 

Our expression language certainly has a description in Desc 1 , but let us define it directly: 
we shall not need to tinker with the structure of expressions, so we may as well see what 
we are doing. 

data Exp : Set where 

val : Nat — > Exp 

plus : Exp — > Exp — > Exp 

The reference semantics is given by a straightforward recursion, which could certainly 
be given as a fold. 

eval : Exp — > Nat 

eval (val n) = n 

eval (plus a b) = eval a + eval b 

Let me direct our primary attention, however, to the stack machine code. For conve- 
nience, I define it as a tree structure with sequential composition as a constructor: one may 
readily flatten the tree at a later stage. For saftey, I index code by the initial and final stack 
height at which it operates. Given directly, we might declare code thus: 

data Code : (Nat x Nat) -> Set where 

PUSH:V{/}-> Nat^ Code (;,suc i) 

ADD : V{z}— > Code (sue (sue i), sue i) 

SEQ : V { ij k} -> Code (ij) -> Code (j,k) -> Code (i,k) 

Note how the indexing ensures that the stack cannot underflow: ADD may only be coded 
when we are sure that the stack holds at least two values and it decrements the stack height; 
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PUSH increments stack height; SEQ ensures that code fragments fit together, domino- 
style. One could, of course, consider Code to be a stack-safe ornament on unsafe code, 
itself an ornament on plain binary trees, but the point of this example is to push in the 
other direction, and add yet more indexing. Accordingly, let us translate this declaration 
systematically to a description. I declare an enumeration for the constructors, then define 
the description by case analysis. 

data Op : Set where PUSH ADD SEQ : Op 

CodeD : Desc (Nat x Nat) 
CodeD = cr Op opCodeD where 

opCodeD : Op -> Desc (Nat x Nat) 

opCodeD PUSH = a Nat A i -> a Nat A _ — > say (i, sue i) 

opCodeD ADD = crNatA/^ say (sue (sue /),suc i) 

opCodeD SEQ = cr Nat A ; — > cr Nat A j ' ^ cr Nat A k -> 
ask (zj) * ask (j,k) * say (i,k) 
Code : (Nat x Nat) -> Set 
Code = Data CodeD 

Now, the semantic object associated with a given code fragment is the function it in- 
duces, mapping an initial stack to a final stack, where stacks are just numeric vectors of the 
required height. 

Sem : (Nat x Nat) -> Set 

Sem (ij) = Vec Nat i -> Vec Nat j 

We can then give the code its semantics by defining the 'execution algebra' for its syntax. 
£, : [ CodeD ] Sem -h Sem 

If we expand the definitions in that type, Agda allows us the following implementation. 

£, : V {(/}-»• [ CodeD ] Sem ij -> Vec Nat (fst ij) -> Vec Nat (snd ij) 

£, (PUSH, _,«, refl) ns = n :: ns 

E, (ADD, _, refl) (n :: m :: ns) — (m + n) :: ns 

E, (SEQ, _, _J,g, refl) ns = 8 (f ns) 

exec : Code -h Sem 
exec = fold £, 

We can now state our objective formally, namely to define 
compile : V {/} — > Exp — > Code (/,suc i) 
such that 

exec (compile e) /is = eval ev.ns 

but as exec is fold £,, let us deploy the above method, and try to define a fancier, manifestly 
correct version: 

compile^- :V{/}(e: Exp) — > Data [algOrn CodeD £,J ((;, sue /),_::_ (eval e)) 
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The ornamented code type is indexed by the code's behaviour, as well as by stack height 
information. We shall only succeed in our efforts if we can deliver code which pushes the 
given expression's value. Here goes nothing! 

compile^ (val _) = ( PUSH, _, _, refl > 

compile 4, (plus ab) = ( SEQ, _, _, _, _, compile^ a, _, ( SEQ, _. _, _, _, compile^ b, _, 
( ADD, _, refl ) 
, refl), refl) 

As you can see, Agda has been able to infer all of the indexing details. The basic plan — 
push values, compile summands then add — was all we had to make explicit. Indeed, we 
were able to suppress even the number pushed in the val case, as no other value satisfies 
the specification! We may now define compile and prove it correct at a stroke! 

compile : V {/} — ► Exp — > Code (/,suc i) 
compile = forget (algOrn CodeD £,) • compile 4 

compileCorrect : V (e : Exp) {/} — > exec (compile {/} e) = _::_ (eval e) 
compileCorrect e — Recomputation CodeD f, (compile 4, e) 

To be sure, this construction took some care and benefited from the simplicity of the 
language involved. For one thing, it was crucial to compile the summands in left-to-right 
order: had we reversed the order, we should have needed the commutativity of + to per- 
suade the type checker to accept compile^. More seriously, we escaped some difficulty 
because our language has only expressions, not control: had we included, say, conditional 
expressions, we should have been obliged to prove that the actual behaviour, choosing 
which branch to execute, is equivalent to the reference behaviour, executing both branches 
and choosing between their values. These proofs are easy, but they are not nothing. 

What, then, is the essence of this method? Rather than programming by iteration then 
proving correctness by the corresponding induction, we do both in tandem. Those steps of 
the proof which amount to rewriting by the inductive hypotheses vanish. For our example, 
that happens to be the whole of the proof. In general, we should expect some obligations 
to survive. Effectively, the construction internalizes aspects of the basic proof strategy 
delivered in Coq by the 'Program' tactics of Catherine Parent and Matthieu Sozeau (Parent - 
Vigouroux, 1997; Sozeau, 2008): these start from a recursive program and initiate a proof 
of its correctness by the corresponding induction, leaving the remaining proof obligations 
for the user. 

10 Discussion 

In this paper, I have exploited a universe construction to give a coding system not only for 
individual datatypes, but for annotation and refinement relationships between datatypes. 
By making these connections explicit and first class, I was able to give generic implemen- 
tations of some standard components typically churned out by hand. From the ornament 
expressing that lists are 'natural numbers with annotations on successor', I acquired the 
length function as the fold of the ornamental algebra, then the notion of vector as an 
algebraic ornament, together with operations to shunt data up the ornamental hierarchy. 
I showed how to acquire cheap proofs for low level programs by using ornaments locally 



ZU064-05-FPR LitOrn 23 January 201 1 1:57 



Ornamental Algebras, Algebraic Ornaments 2 1 

to work at a higher level of precision in the first place. My experiments take the form of 
Agda programs, typed, total, and available online. 

I hasten to add that I do not claim ornaments provide a viable, scalable methodology 
for Agda programming, or that the rudimentary universe I use in this paper is optimal in 
practice. Rather, I am grateful that Agda provides a convenient platform for experimenting 
with the basic idea and delivering proof of concept. Before we can really get to work with 
this technology, however, we must ensure that our programming languages are geared to 
support it. Agda delivers a pleasant programming experience for its native data-declared 
types: it is far from pleasant to construct and manipulate their encoded counterparts in our 
universe, but not for any deep reason. Good language support for encoded data has not, 
thus far, been a priority, but it is surely possible to repurpose the existing data declaration 
as mere sugar for the definition of the corresponding code, and to ensure that those codes 
carry enough information (e.g., about constructor names, implicit argument conventions, 
and so forth) to sustain the readability to which we are accustomed. 

Libraries should deliver encoded datatypes, to be taken as themes for local variation, 
ensuring that programmers can work with the precision appropriate to the task at hand 
without compromising the broader exchange of data. We should not lose the general func- 
tionality of a list library just because it is sometimes convenient to work with the precision 
of vectors, or ordered lists, or ordered vectors, or any of the other multifarious possibilities 
which we are now free to farm. At the same time, we might develop libraries of ornaments. 
Nobody should have to think about how to index a particular data structure by its number 
of nodes, or a bound on its depth, or its flattening to a sequence: such recipes belong 
in the repertoire. Declaring — rather than defining — datatypes should now be seen as an 
impediment to the properly compositional data design process, punished by payment for 
what is rightfully free. As the Epigram team has shown, it is not even necessary to declare 
the datatype which is used for the descriptions of datatypes: with care, and a handful of 
predefined components, a sufficiently expressive universe can be persuaded to appear as if 
it is self-encoded (Chapman et ai, 2010). 

We are ready to begin an ornamental reimagining of programming. Once aware of the 
annotation relationship between numbers and lists, for example, we can ask just what extra 
is needed to develop concatenation from addition. Intuitively, we should just require a 
function to compute the decoration for the output successor from the decoration on the 
input successor: if we work polymorphically, parametricity tells us there is no choice for 
the output but to copy the input. By starting not from thin air and inspiration, but rather 
from a tangible template, we should not only save perspiration, but also achieve greater 
perspicuity. The proof that the length of a concatenation is the sum of the lengths of its 
pieces currently requires us to observe a coincidence, when it should rather be the direct 
consequence of an ornamental construction. 

There is much to do, both in theory and in practice. On the theory side, we should seek 
a more abstract characterization of ornaments, independent of the particular encoding of 
datatypes at work. The theory of containers and indexed containers seem apt to the task and 
an exploration is in progress (Abbott et ai, 2005; Altenkirch & Morris, 2009). We should 
also consider alternative formulations of ornamentation, perhaps as a relation between two 
descriptions yielding a forgetful map from one to the other. Where in this paper, I consider 
only insertion of new information, we might also want to delete old information, provided 
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we give a way to recover it in the forgetful map. Combining insertion with deletion, we 
would acquire the general facility to rearrange data structures provided the overall effect 
is to upgrade with more information. The idea of extending a datatype, stood on its head, 
is an ornament of this character — restricting constructor choice generates a more specific 
type which obviously embeds in the original. A formal understanding of the corresponding 
modifications to programs might have a profound impact on engineering practice, reducing 
the cost of change. 

In practical terms, a key question is just how this technology should be delivered to the 
programmer. How do I give a datatype, not as a standalone declaration, but as an ornament? 
How do I collect my free programs and theorems? At the moment, our usual means to refer 
to particular components of index information tends to be rather positional and is thus 
unlikely to scale: can we adapt record types to fit this purpose? Can we minimize the cost 
of changing representations? It should be possible to store an ornamented data structure 
as the dependent pair of the plain data with its ornamental extras, manipulating the two in 
sync, and ensuring that the forgetful function is a constant-time projection in practice. For 
algebraic ornaments, the additional information is effectively propositional — the evidence 
for the recomputation lemma — and should thus require no run-time space. 

Meanwhile, there are plenty of ornaments which are not algebraic: what other ornament 
patterns can we identify and systematize? Where algebraic ornaments bubble descriptive 
indices up from the leaves, there must surely be ornaments which push presciptive indices 
down from the root or thread before-and-after indices in a static traversal of the data. We 
can write first-class programs with attribute grammars (Viera et al, 2009) — let us also 
apply a similarly compositional analysis to first-class types. 

Dependent types are attractively principled, but they will catch on in practice only when 
they enable the programmers who use them to outperform the programmers who do not. 
In certain specialised fields where precision is at a particular premium it can be profitable 
to bash away with today's technology, armed to the teeth with the latest tactics. But where 
productivity is the key, it is the programs we need not write ourselves which determine the 
effectiveness of a technology. The key to constructing programs is the organisation of data, 
and that is at last in our hands. 
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